Debt Recordation to Blockchains

ABSTRACT

Accounts receivables, accounts payables, and other debt instruments are registered to blocks of data in a blockchain. The blockchain may then be dispersed to subscribers for inspection. Any subscriber may inspect the blockchain, evaluate the debt instruments registered to the blockchain, and conduct automated, electronic purchases of any debt instruments. Smart, digital contracts executed by the blockchain may automate purchase of the debt instruments.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application is a continuation of U.S. application Ser. No.16/191,585 filed Nov. 15, 2018 and since issued as U.S. Pat. No. ______,which claims domestic benefit of U.S. Provisional Application No.62/743,061 filed Oct. 9, 2018, with both patent applicationsincorporated herein by reference in their entireties.

BACKGROUND

Liquidity can be a problem for suppliers. When any supplier of a productor service wishes to grow, cash is usually required for inventory,equipment, and operations. Cash liquidity, though, is often inadequate,especially for a small business. Many suppliers will thus sell accountsreceivables (e.g., debt) in credit markets to raise cash. These debt orcredit markets, though, are costly and may require high interest rates.What is needed, then, is a marketplace with reduced transaction costs.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The features, aspects, and advantages of the exemplary embodiments areunderstood when the following Detailed Description is read withreference to the accompanying drawings, wherein:

FIGS. 1-21 are simplified illustrations of a blockchain marketplace,according to exemplary embodiments;

FIGS. 22-26 are more detailed illustrations of an operating environment,according to exemplary embodiments;

FIGS. 27-31 illustrate a blockchain data layer, according to exemplaryembodiments;

FIGS. 32-35 are detailed illustrations of an account receivable,according to exemplary embodiments;

FIGS. 27-31 further illustrate the blockchain data layer, according toexemplary embodiments;

FIGS. 32-35 are more detailed illustrations of the account receivable,according to exemplary embodiments;

FIGS. 36-37 illustrate an account payable, according to exemplaryembodiments;

FIGS. 38-39 illustrate login procedures, according to exemplaryembodiments;

FIG. 40 is a flowchart illustrating a method or algorithm for debttransactions, according to exemplary embodiments; and

FIGS. 41-42 depict still more operating environments for additionalaspects of the exemplary embodiments.

DETAILED DESCRIPTION

The exemplary embodiments will now be described more fully hereinafterwith reference to the accompanying drawings. The exemplary embodimentsmay, however, be embodied in many different forms and should not beconstrued as limited to the embodiments set forth herein. Theseembodiments are provided so that this disclosure will be thorough andcomplete and will fully convey the exemplary embodiments to those ofordinary skill in the art. Moreover, all statements herein recitingembodiments, as well as specific examples thereof, are intended toencompass both structural and functional equivalents thereof.Additionally, it is intended that such equivalents include bothcurrently known equivalents as well as equivalents developed in thefuture (i.e., any elements developed that perform the same function,regardless of structure).

Thus, for example, it will be appreciated by those of ordinary skill inthe art that the diagrams, schematics, illustrations, and the likerepresent conceptual views or processes illustrating the exemplaryembodiments. The functions of the various elements shown in the figuresmay be provided through the use of dedicated hardware as well ashardware capable of executing associated software. Those of ordinaryskill in the art further understand that the exemplary hardware,software, processes, methods, and/or operating systems described hereinare for illustrative purposes and, thus, are not intended to be limitedto any particular named manufacturer.

As used herein, the singular forms “a,” “an,” and “the” are intended toinclude the plural forms as well, unless expressly stated otherwise. Itwill be further understood that the terms “includes,” “comprises,”“including,” and/or “comprising,” when used in this specification,specify the presence of stated features, integers, steps, operations,elements, and/or components, but do not preclude the presence oraddition of one or more other features, integers, steps, operations,elements, components, and/or groups thereof. It will be understood thatwhen an element is referred to as being “connected” or “coupled” toanother element, it can be directly connected or coupled to the otherelement or intervening elements may be present. Furthermore, “connected”or “coupled” as used herein may include wirelessly connected or coupled.As used herein, the term “and/or” includes any and all combinations ofone or more of the associated listed items.

It will also be understood that, although the terms first, second, etc.may be used herein to describe various elements, these elements shouldnot be limited by these terms. These terms are only used to distinguishone element from another. For example, a first device could be termed asecond device, and, similarly, a second device could be termed a firstdevice without departing from the teachings of the disclosure.

FIGS. 1-21 are simplified illustrations of a blockchain marketplace 20,according to exemplary embodiments. The blockchain marketplace 20records electronic transactions of goods and/or services. For example,when any product 22 is bought, sold, contracted, or loaned, a server 24records the corresponding electronic transaction 26 a to a block 28 a ofdata in a blockchain 30. The block 28 a of data may describe anyelectronic transactional data 32 a associated with the transaction 26 a,such as the buyer/seller, date, purchase/sale amount, and even location(such as GPS coordinates). Similarly, whenever any service 34 is bought,sold, contracted, or bartered, the server 24 may record thatcorresponding transaction 26 b to the block 28 b of data in theblockchain 30, and the block 28 b of data may document the correspondingelectronic transactional data 32 b.

FIG. 2 illustrates subsequent transfers. Here exemplary embodiments mayrecord second-hand, third-hand, and other sales of the product 22. Asthe reader may understand, an original owner of the product 22, for manyreasons, may later sell the product 22 to another party. Thesesubsequent transactions are common in homes, vehicles, antiques, andjewelry. Regardless, whenever the product 22 is subsequently bought,sold, contracted, or loaned, the corresponding transaction 26 c isrecorded to still another block 28 c of data in the blockchain 30. Theblock 28 c of data may again record any electronic transactional data 32associated with the transaction 26 c, such as the buyer, the seller, thedate, and the purchase/sale amount. Simply put, whenever the product 22is transferred, each transfer may be recorded to any of the blocks 28 ofdata within the blockchain 30. The blockchain 30 thus creates adistributed, immutable ledger that provides evidentiary documentation ofeach transfer of the product 22.

FIG. 3 illustrates debt recordations. Here the blockchain 30 may alsoregister debts, loans, liens, lines of credit, and any other electronicdebt information 36 a. As the reader may understand, when the product 22is sold, a debt 38 a may be incurred. The purchaser may obtain a loan tofund the purchase, especially for high-dollar products (such as homes,vehicles, and jewelry). Usually some form of collateral backs the loan,which may be the product 22 itself. Regardless, the block 28 of data mayalso record any of the electronic transactional data 32 a and/or theelectronic debt information 36 a associated with the transaction 26 a,such as the bank, credit union, financial institution, or private entitythat funds or backs the debt. Moreover, the electronic debt information36 a may also describe payment terms, length or number of payments,interest rate, and a beginning or original balance. Similarly, if thedebt 38 b is incurred for the service 34, exemplary embodiments mayrecord the corresponding electronic transactional data 32 b and/or theelectronic debt information 36 b to the block 28 of data in theblockchain 30. The blockchain marketplace 20 thus creates a distributed,immutable ledger that provides evidentiary documentation of the debt 38and its terms.

FIG. 4 illustrates debt updates. After the blockchain 30 records theinitial electronic debt information 36, subsequent payments 40 may alsobe recorded. Again, as the reader may understand, when the purchaseraccepts a loan for the product 22, one or more payments 40 may berequired (as is common for homes, vehicles, and jewelry). Exemplaryembodiments may thus record each subsequent or successive payment 40 tothe blockchain 30. That is, each payment 40 may be another transaction26 recorded to still another block 28 of data in the blockchain 30. Theblock 28 of data may again record any electronic transactional data 32and/or the electronic debt information 36 associated with the payment40, such as the debtor, the date, the payment, timeliness,fees/interest/balance, and remaining payments. The blockchain 30 mayalso record the final payment 40 that extinguishes or satisfies the debt38, along with its corresponding date and location. Similarly, if a debtis incurred for the service 34, exemplary embodiments may record thecorresponding electronic transactional data 32 and/or the electronicdebt information 36 to the block 28 of data in the blockchain 30. Theblockchain 30 thus creates a distributed, immutable ledger that providesevidentiary documentation of each payment 40 and a final satisfaction ofthe debt 38.

FIG. 5 illustrates accounts receivables 50. Here the blockchain 30 mayalso register accounts receivables 50 and other monies owed betweenparties. As the reader may understand, the accounts receivables 50 arecommon accounting practices, especially in supplier/vendorrelationships. When a supplier 52 sells its product 22 or service 34 toa buyer 54, delivery may be immediate or relatively soon. Payment,though, may be delayed 45-90 days after invoicing. As a simple example,suppose the WALMART® corporation purchases thousands of the product 22from the supplier 52. The supplier 52 submits the products 22 intoWalmart's distribution system, the supplier 52 invoices WALMART® for theproducts 22, and the supplier 52 may then wait 45-90 days for payment.Exemplary embodiments may thus also record the account receivable 50 tothe blockchain 30. The block 28 of data, for example, may also recordthe electronic transactional data 32 describing the account receivable50, such as the buyer 54 (or debtor 56) and the supplier 52, the date ofthe account receivable 50, and the payment terms. Simply put, exemplaryembodiments may fully describe and record the account receivable 50 tothe blockchain 30. The blockchain 30 thus creates a distributed,immutable ledger that provides evidentiary documentation of the accountreceivable 50.

FIG. 6 illustrates subsequent sales of the account receivable 50. Eventhough the supplier 52 may have accepted the account receivable 50, thesupplier 52 may sell the account receivable 50 for immediate cash. Thesupplier 52, alternatively, may offer the account receivable 50 ascollateral/credit for a loan. Regardless, the account receivable 50 maybe transferred or sold to a different party (such as a debt buyer ordebt purchaser 58). Exemplary embodiments may thus also recordsubsequent transfers or sales of the account receivable 50 to theblockchain 30. When the account receivable 50 is bought, sold, orcontracted, the corresponding transaction 26 is recorded to another oneof the blocks 28 of data in the blockchain 30. The block 28 of datarecords the electronic transactional data 32, such as the buyer/seller,date, purchase/sale amount, and even location (such as GPS coordinates).

FIG. 7 illustrates payment of the account receivable 50. When theaccount receivable 50 is partially or fully paid, exemplary embodimentsmay update the blockchain 30. Any payment 40 may be registered/recordedto the blockchain 30, along with its corresponding electronictransactional data 32. The final satisfaction of the account receivable50 may also be recorded to the blockchain 30, along with itscorresponding date and location. The blockchain 30 thus creates adistributed, immutable ledger that provides evidentiary documentation ofeach payment 40 and final satisfaction of the account receivable 50.

FIG. 8 illustrates verification of the account receivable 50. Eventhough the account receivable 50 may be registered on the blockchain 30,exemplary embodiments may include a verification 60 that the accountreceivable 50 is legitimate and accurate. FIG. 8, for example,illustrates an encryption 62 of the electronic transactional data 32describing the account receivable 50. While any encryption scheme may beused, the electronic transactional data 32 may be encrypted using acryptographic key 64 that is unique to the supplier 52. That is, perhapsonly the supplier 52 knows of its unique or private suppliercryptographic key 64. The supplier 52 may thus cryptographically signthe account receivable 50 and record an encrypted account receivable 66to the blockchain 30. Because the account receivable 50 is encryptedusing the supplier's or vendor's cryptographic key 64, thesupplier/vendor immediately verifies that the encrypted accountreceivable 66 is legitimate and accurate. Any account receivables 50recorded to the blockchain 30 that are not encrypted with the supplier'scryptographic key 64 could be fraudulent.

FIG. 9 illustrates another verification of the account receivable 50.Here the buyer 54 or debtor 56 associated with the account receivable 50may include its verification 60 that the account receivable 50 islegitimate and accurate. Suppose again that WALMART® buys thousands ofthe product 22 from the supplier 52. When the supplier 52 invoicesWALMART® for the products 22 and accepts the account receivable 50,WALMART® may self-certify that the account receivable 50 is legitimateand accurate. For example, the buyer 54 or debtor 56 associated with theaccount receivable 50 may encrypt the electronic transactional data 32describing the account receivable 50 using a unique or private debtor'scryptographic key 70. The buyer 54 may thus cryptically sign the accountreceivable 50 and record the encrypted account receivable 66 to theblockchain 30, thus self-verifying its legitimacy and accuracy. Anyaccount receivables 50 recorded to the blockchain 30 that are claimed tobe owed by WALMART® but not encrypted with the Walmart's cryptographickey 70, could be fraudulent.

FIG. 10 illustrates still another verification of the account receivable50. Here both the debtor 56 and the supplier 52 may jointly verify thatthe account receivable 50 is legitimate and accurate. Exemplaryembodiments may thus encrypt the electronic transactional data 32describing the account receivable 50 with the supplier's cryptographickey 64 and the debtor's cryptographic key 70. Because both the debtor 56and the supplier 52 may cryptically sign the account receivable 50, boththe debtor 56 and the supplier 52 verify that the account receivable 50(and/or its corresponding encrypted account receivable 66) is legitimateand accurate. Again, then, any account receivables 50 recorded to theblockchain 30 that are claimed to be owed to the supplier 52 by thedebtor 56, but not encrypted with supplier's cryptographic key 64 andthe debtor's cryptographic key 70, could be fraudulent.

FIG. 11 illustrates accounting verification. Here exemplary embodimentsmay describe the supplier's accounting system that generates the accountreceivable 50. Suppose, for example, that the server 24 operates onbehalf of the supplier 52, and the server 24 stores and executes thesupplier's accounting software application 72. The server 24 executesthe supplier's accounting software application 72 to generate theelectronic transactional data 32 describing the transaction 26 and theaccount receivable 50. Here, though, the electronic transactional data32 may also include any data or information describing the supplier'saccounting software application 72. FIG. 11, for example, illustrates apublic and/or private software cryptographic key 74 that is unique tothe supplier's accounting software application 72. The supplier'saccounting software application 72 may thus cryptographically sign theaccount receivable 50 and record its corresponding encrypted accountreceivable 66 to the blockchain 30. Because the electronic transactionaldata 32 describing the account receivable 50 may be encrypted using thesoftware cryptographic key 74 that is unique to the supplier'saccounting software application 72, the supplier 52 and/or thesupplier's accounting software application 72 may also verify that theaccount receivable 50 is legitimate and accurate. Any accountreceivables 50 recorded to the blockchain 30 that are claimed to be owedto the supplier 52, but not encrypted with supplier's softwarecryptographic key 74, could be fraudulent.

Cryptographic credentials provide the verification 60. Not only may theaccount receivable 50 be registered to the blockchain 30, but theblockchain 30 may also detail information about the supplier'saccounting software application 72 in a cryptographic way, such that theinformation may be checked using the same cryptographic credentials. Anythird party that wishes to verify the account receivable 50 (such as aninterested or bidding debt buyer or debt purchaser) may inspect theblockchain 30 and check a status of the account receivable 50. Again,then, the blockchain 30 creates a distributed, immutable ledger thatprovides evidentiary documentation of the account receivable 50generated by the supplier's accounting software application 72.

FIG. 12 illustrates the supplier's accounting report 76. As the readermay understand, the supplier's accounting software application 72 maygenerate the supplier's accounting report 76 that describes thetransaction 26, including the account receivable 50. Here, though, thesupplier's accounting software application 72 may also generate one ormore supplier's authentication credentials 78. The supplier'sauthentication credentials 78 may be unique to the supplier's accountingreport 76. When the transaction 26 is written to the blockchain 30,exemplary embodiments may also record the supplier's accounting report76 to the block 28 of data in the blockchain 30. The supplier'saccounting report 76 may again describe the debtor 56, the supplier 52,the date of the account receivable 50, the payment terms, and any otherrelevant or desired data. However, exemplary embodiments mayadditionally or alternatively record or register the supplier'sauthentication credentials 78 for accessing the supplier's accountingreport 76. Moreover, exemplary embodiments may also cryptographicallysign the supplier's accounting report 76 and/or the supplier'sauthentication credentials 78. Again, while any encryption scheme may beused, exemplary embodiments may use the supplier's cryptographic key 64and/or the supplier's software cryptographic key 74. The supplier 52 maythus cryptographically sign the account receivable 50, the supplier'saccounting report 76, and/or the supplier's authentication credentials78 to the blockchain 30. Because the electronic transactional data 32may be encrypted using the supplier's software cryptographic key 74, thesupplier's accounting software application 72 verifies that the accountreceivable 50, the supplier's accounting report 76, and/or thesupplier's authentication credentials 78 is/are legitimate and accurate.Any entries in the blockchain 30 not encrypted with the supplier'ssoftware cryptographic key 74 could be unverified and/or fraudulent.

FIG. 13 illustrates permissioned access. As the reader likelyunderstands, the supplier's accounting software application 72 may havea login procedure 80. Because the authentication credentials 78 may beregistered in the block 28 of data in the blockchain 30, any interestedparty may inspect the block 28 of data and identify and retrieve theauthentication credentials 78 (e.g., username, password, two-factorsystem, and/or biometric file). Those authentication credentials 78 maythen be submitted to the login procedure 80 to the supplier's accountingsoftware application 72. If the authentication credentials 78 aresuccessful, then the user may have access to the to the supplier'saccounting report 76. Suppose, for example, that the blockchain 30 isreceived as an input by a client server 82. The client server 82 may beoperated on behalf of any third-party that receives or subscribes to theblockchain 30 as a client. While the third party may be any public orprivate entity, the third party may be the potential debt buyer 58 whois conducting due diligence before purchasing the account receivable 50.The client server 82 executes a client-side software application 84 thatinstructs the client server 82 to receive the blockchain 30, read theblock 28 of data, and obtain the authentication credentials 78. As asimple example, the client-side software application 84 may be acomponent or module of a digital or smart contract 86 that is capable ofreading the blockchain 30. Once the client server 82 retrieves theauthentication credentials 78, the client-side software application 84instructs the client server 82 to submit the authentication credentials78 to the login procedure 80 to the supplier's accounting softwareapplication 72. Because the supplier's authentication credentials 78were generated by the supplier's accounting software application 72, theauthentication credentials 78 should successfully authenticate.

Permissioned access, though, may be limited. Because the supplier'sauthentication credentials 78 may be specific to the supplier'saccounting report 76, the accessing user (such as the client server 82)may be limited to accessing only the supplier's accounting report 76.The supplier's authentication credentials 78, in other words, mayself-select and/or be associated with an access permission and/or a rolethat allows strictly limits access and retrieval of only the supplier'saccounting report 76. The user may thus only have permission to accessdata or information associated with the supplier's accounting report 76(e.g., the electronic transactional data 32 describing the transaction26 that logs the account receivable 50, as explained with reference toFIG. 12). In other words, the supplier's accounting report 76 may onlybe as detailed as the authentication credentials 78 permit. Other data,such as different transactions or different accounting reports, may beinaccessible and unauthorized.

FIG. 14 illustrates an example that helps explains the supplier'saccounting report 76. Suppose again that WALMART® contracts with thesupplier 52 to purchase the product 22. The supplier's server 24executes the supplier's accounting software application 72,autogenerates an invoice 90, enters or logs the account receivable 50,and generates the supplier's accounting report 76. The supplier's server24 then registers the transaction 26 (e.g., the account receivable 50)to the block 28 of data within the blockchain 30. The account receivable50 and/or the block 28 of data may also be cryptographically signed (asabove explained). The client server 82 may then receive the blockchain30 and read the block 28 of data. The client server 82, in other words,may be programmed to receive and inspect the blockchain 30 for the block28 of data detailing the account receivable 50. If the accountreceivable 50 satisfies one or more decision parameters 92, then thedebt buyer 56 may bid on or even buy the account receivable 50. Indeed,the digital or smart contract 86 may execute on the blockchain 30 toautomate the bidding and purchasing process. The client server 82 and/orthe smart contract 86 may decrypt the transaction 26 (e.g., the accountreceivable 50), read the supplier's authentication credentials 78, login to the supplier's accounting software application 72, and access thesupplier's accounting report 76.

The buyer may inspect the supplier's accounting report 76. If thesupplier's authentication credentials 78 only grant permission access tothe supplier's accounting report 76, the buyer's server 24 may onlyaccess the electronic transactional data 32 describing the transaction26 and the account receivable 50. Suppose the supplier's invoice 90 isnumbered “32968” and details a debt or amount owed by WALMART® to thesupplier 52. The potential debt buyer 56 may use the supplier'sauthentication credentials 78 written into the transaction 26 to accessthe supplier's accounting report 76 and/or its associated invoice 90.The potential debt buyer 58 may thus confirm or verify the existence ofthe account receivable 50 by reading/retrieving the supplier'saccounting report 76 detailing the supplier's invoice 90 “32968.”Exemplary embodiments may thus be analogized to a patient's medicalrecords. The patient may authorize a physician to only access aparticular medical record. The patient, in other words, may establishaccess credentials that only permit or specify the particular medicalrecord. The supplier's authentication credentials 78 written into theblockchain 30 may thus be a “front door” to only the transaction 26, thesupplier's accounting report 76, and/or its associated invoice 90.

Exemplary embodiments thus reduce fraud and transaction costs.Conventional debt markets are subject to fraudulent sales of accountsreceivables and other debt. Debt sales are conducted without accurateverification of the existence and/or terms of the debt. Fraud increasesthe risk on brokers and agents, which increases the transactional costsin debt sales. Exemplary embodiments, instead, solve the problem offraud in secondary market transactions for debt. Because the buyer ofthe debt 38 is now given access to the actual supplier's accountingreport 76, the buyer may quickly and simply verify existence of theaccount receivable 50. The verification 60 will reduce the transactionalcosts and interest rates. The corollary is that if the supplier 52denies access to the supplier's accounting report 76, potential buyerswill assume a greater risk exists and interest rates will increase.Exemplary embodiments thus implement a market mechanism that holdsaccountable and the blockchain 30 records and proves any attempted readsand any attempted writes.

FIG. 15 illustrates a debtor's account payable 100. As the reader mayunderstand, when the debtor 56 defers a payment to the supplier 52, thedebtor 56 incurs the account payable 100. Suppose again that WALMART®contracts with the supplier 52 as the debtor 56 and owes the debt 38,perhaps as described or specified by the invoice 90. WALMART® thus has adebtor's accounting system that logs or enters the invoice 90 as theaccount payable 100. FIG. 15 illustrates Walmart's accounting system asa debtor's server 102 that stores the debtor's accounting softwareapplication 104. The debtor's server 102 executes the debtor'saccounting software application 104 to generate the electronictransactional data 32 describing the transaction 26 and the debtor'saccount payable 100. The electronic transactional data 32, however, mayalso include any data or information describing the debtor's accountingsoftware application 104, such as another unique public and/or privatedebtor's cryptographic key 106 that is unique to the debtor 56 and/orthe debtor's accounting software application 104. The debtor'saccounting software application 104 may thus cryptographically sign theaccount payable 100 and record an encrypted account payable 108 to theblockchain 30. Because the account payable 100 may be encrypted usingWalmart's unique/private cryptographic key 106, WALMART® and/or itsdebtor's accounting software application 104 verifies that the accountpayable 100 is legitimate and accurate. Any entries in the blockchain 30not encrypted with Walmart's unique/private cryptographic key 106 couldbe unverified and/or fraudulent.

FIG. 16 illustrates a debtor's accounting report 110. Here the debtor'saccounting software application 104 may generate the debtor's accountingreport 110 that describes the transaction 26 and the account payable100. The debtor's accounting software application 104 may also generateone or more debtor's authentication credentials 112 that are unique tothe debtor's accounting report 110. When the transaction 26 is writtento the blockchain 30, exemplary embodiments may also record the debtor'saccounting report 110 to the block 28 of data in the blockchain 30(e.g., the debtor/buyer 54, the supplier 52, the date of the accountpayable 100, the payment terms, and any other relevant or desired data).However, exemplary embodiments may additionally or alternatively recordor register the debtor's authentication credentials 112 for accessingthe debtor's accounting report 110. Moreover, exemplary embodiments mayalso cryptographically sign the debtor's accounting report 110 and/orthe debtor's authentication credentials 112. Again, while any encryptionscheme may be used, exemplary embodiments may use the debtor'scryptographic key 106 that uniquely identifies the debtor 56 and/or thedebtor's accounting software application 104. The account payable 100,the debtor's accounting report 110, and/or the debtor's authenticationcredentials 112 may be cryptographically signed to the blockchain 30.The debtor 56 and/or the debtor's accounting software application 104may thus verify that the account payable 100, the debtor's accountingreport 110, and/or the debtor's authentication credentials 112 is/arelegitimate and accurate. Any entries in the blockchain 30 not encryptedwith the debtor's cryptographic key 106 could be unverified and/orfraudulent.

FIG. 17 illustrates how accounting cryptology again preservespermissioned access. As the reader likely understands, the debtor'saccounting software application 104 may also have a debtor's loginprocedure 114. The client server 82 receives the blockchain 30, readsthe block 28 of data, obtains the data or information associated withthe account payable 100 and/or its the encrypted version 108. If theaccount payable 100 satisfies the decision parameters 92, then the debtbuyer 58 may have sufficient confidence that the corresponding accountreceivable 50 is authenticate and/or correct. Indeed, the digital orsmart contract 86 may execute on the blockchain 30 to automate thebidding and purchasing process. The client server 82 and/or the smartcontract 86 may decrypt the transaction 26 (e.g., the account receivable50), read the debtor's authentication credentials 112, log in to thedebtor's accounting software application 104, and access the debtor'saccounting report 110. Again, then, the debtor's authenticationcredentials 112 may limit access to only the debtor's accounting report110. The debtor's authentication credentials 112, in other words, mayself-select and/or be associated with an access permission and/or a rolethat strictly limits access and retrieval of only the debtor'saccounting report 110. Other data, such as different transactions ordifferent accounting reports, may be inaccessible and unauthorized.

Debt buyers may access the debtor's accounting report 110. When thedebtor's server 102 registers the account payable 100 to the block 28 ofdata within the blockchain 30, potential debt buyers may receive theblockchain 30 and read the block 28 of data. The potential buyer'sclient server 82, in other words, may be programmed to receive andinspect the blockchain 30 for the block 28 of data detailing the accountpayable 100. If the account payable 100 satisfies the one or moredecision parameters 92, then the debt buyer 56 may bid on or even buythe corresponding account receivable 50. Again, the digital or smartcontract 86 may execute on the blockchain 30 to automate the bidding andpurchasing process. The client server 82 and/or the smart contract 86may decrypt the transaction 26 (e.g., the account receivable 50 and/orthe account payable 100), read the debtor's authentication credentials112, log in to the debtor's accounting software application 104, andaccess the debtor's accounting report 110.

The buyer may inspect the debtor's accounting report 110. If thedebtor's authentication credentials 112 only grant permission access tothe debtor's accounting report 110, the client server 82 and/or thesmart contract 86 may only access the electronic transactional data 32describing the transaction 26 and the account payable 100. The potentialdebt buyer 58 may use the debtor's authentication credentials 112written into the transaction 26 to access the debtor's accounting report110 and/or its associated invoice 90. The potential debt buyer 58 maythus confirm or verify the existence of the account payable 100 and/orthe corresponding account receivable 50 by reading/retrieving thedebtor's accounting report 110 detailing the supplier's invoice 90. Thedebtor's authentication credentials 112 written into the blockchain 30may thus be a “front door” to only the transaction 26, the debtor'saccounting report 110, and/or its associated invoice 90.

Fraud and costs are again reduced. The potential debt buyer 58 (e.g.,the client server 82 and/or the digital or smart contract 86 executed onthe blockchain 30) may access both the debtor's accounting report 110and the supplier's accounting report 76 (as explained with reference toFIGS. 11-13). The client server 82 and/or the digital or smart contract86 may be programmed to compare the supplier's transactional data 32 tothe debtor's transactional data 32. Simply put, if the data describingthe account receivable 50 matches, nearly matches, or sufficientlycoincides with the data describing the account payable 100, then thepotential debt buyer 58 may have confidence to bid/buy. The accountreceivable 50 is verified. However, if the account receivable 50 failsto sufficiently match or satisfy the account payable 100, fraud may bepresent. A difference or discrepancy in risk, costs, and/or interestrates may thus indicate potential fraud and require greater human ormachine scrutiny. Exemplary embodiments thus allow buyers of debt andother financial instruments to inspect each party's accounting recordsusing a blockchain environment.

Payments may also be verified. The above paragraphs explained how thepayment 40 of the account receivable 50 may be recorded to theblockchain 30 for inspection. Exemplary embodiments, then, may allowboth the debtor 56 and the supplier 52 to record any payment 40. Forexample, when the debtor 56 (again, such as WALMART®) makes a partial orfull payment of the account receivable 50 and/or the account payable100, the debtor's accounting software application 104 may generateanother of the debtor's accounting report 110 that describes thecorresponding transaction 26. Moreover, the debtor's authenticationcredentials 112 may also be generated and written to the blockchain 30(as above explained). Similarly, the supplier's accounting softwareapplication 72 may generate another of the supplier's accounting reports76 that describes the corresponding transaction 26, along with thesupplier's authentication credentials 78 (as also above explained). Thepotential debt buyer 58 (e.g., the client server 82 and/or the digitalor smart contract 86 executed on the blockchain 30) may access both themost recent debtor's accounting report 110 and the most recentsupplier's accounting report 76 to verify that the debt 38 is stilloutstanding. If a comparison confirms that a debt balance still exists,the potential buyer 54 may bid/buy the account receivable 50. However,if the account receivable 50 has been paid or satisfied, then the server24 and/or the digital or smart contract 86 may abandon the purchase andalert of potential fraud.

Exemplary embodiments may also allow anonymous viewing. Because theauthentication credentials 78 and 112 may be published to the blockchain30, any party may read the blockchain 30, obtain the authenticationcredentials 78 and 112, logon to the respective accounting softwareapplications 72 and 104, and access the corresponding accounting reports76 and 110. Any buyer or third party having access to the blockchain 30may anonymously check the status of the account receivable 50 and/or theaccount payable 100. This viewing opportunity will greatly increase thetransparency of debt obligations as compared to today's conventionaldebt markets. Moreover, because the blockchain 30 may be publishedaccording to a subscription or even public distribution, the blockchain30 will be available to far more potential buyers than today'sconventional debt markets. The need for middle brokers and agents, andtheir associated fees and costs, are greatly reduced or even eliminated.Still more advantageous, because debt verification may be automated (viathe servers 24, 82, 102, and/or the smart contract 86), debt sales willbe conducted in much less time with much less or little human effort.All these advantages reduce fraud and costs.

Dedicated reporting may be used. The blockchain 30 may be dedicated toaccounts receivables 50 associated with the supplier 52 and/or thedebtor 56. As the reader may again understand, the supplier 52 may havemany accounts receivables 50 with many customers. The supplier 52, then,may wish to record any or all of the accounts receivables 50 to a singleor common blockchain 30. The blockchain 30, in other words, may bededicated to publishing the supplier's accounts receivables 50 to a poolor to subscribers of potential debt buyers. Each potential buyer thatreceives the blockchain 30 may inspect the accounts receivables 50 andbid, buy, or pass. Because the supplier 52 may distribute its accountsreceivables 50 via the blockchain 30, the supplier 52 may reduce itscosts and interest rates when offering its sales.

FIG. 18 illustrates a blockchain data layer 120. The blockchain datalayer 120 is a mechanism that also records the account receivable 50from the supplier 52. The blockchain data layer 120 is created by a datalayer server 122 that interfaces with the supplier's server 24. When thesupplier's server 24 and/or the supplier's accounting softwareapplication 72 generates the blockchain 30 documenting the accountreceivable 50 and/or the supplier's authentication credentials 78, thesupplier's server 24 distributes or sends the blockchain 30 to thenetwork address (e.g., Internet protocol address) associated with thedata layer server 122. The data layer server 122 then generates datarecords 124 in the blockchain data layer 120 that also describe theaccount receivable 50 and/or the supplier's authentication credentials78 (as later paragraphs will explain). Moreover, the blockchain datalayer 120 may also add another layer of cryptographic hashing togenerate a public blockchain 126. The blockchain data layer 120 acts asa validation service 128 that validates the account receivable 50 and/orthe supplier's authentication credentials 78. Moreover, the blockchaindata layer 120 may generate a cryptographic proof 130. The publicblockchain 126 thus publishes the cryptographic proof 130 as a publicledger 132 that establishes chains of blocks of immutable evidence. Theblockchain data layer 120 thus generates the public blockchain 126 as apublic resource or utility for record keeping. Any party, entity, ordevice that subscribes to the blockchain data layer 120 may thus access,read, and/or store the proofs 130 of the account receivable 50 and/orthe supplier's authentication credentials 78. The blockchain data layer120, in other words, acts as the public ledger 132 that establisheschain of blocks of immutable evidence. Interested debt buyers mayinspect the public blockchain 126, obtain the supplier's authenticationcredentials 78, retrieve the supplier's accounting report 76, and bid,buy, or pass.

FIG. 19 illustrates proof of the account payable 100. Recall that thedebtor's accounting software application 104 may generate the blockchain30 documenting the account payable 100 and/or the debtor'sauthentication credentials 112. The debtor's server 102 may thendistribute or send the blockchain 30 to the network address (e.g.,Internet protocol address) associated with the data layer server 122.The data layer server 122 then generates the data records 124 in theblockchain data layer 120 that also describe the account payable 100and/or the debtor's authentication credentials 112. The blockchain datalayer 120 generates the public blockchain 126 as the validation service128 that validates the account payable 100 and/or the debtor'sauthentication credentials 112. The public blockchain 126 also publishesthe cryptographic proof 130 as the public ledger 132 that establisheschains of blocks of immutable evidence.

Two party verification is possible. Because both the account receivable50 and the account payable 100 may be registered to the blockchain datalayer 120 (as FIGS. 18-19 illustrate), the blockchain data layer 120 maybe a quick and simple verification mechanism for debt sales. Again, anyparty, entity, or device that subscribes to the blockchain data layer120 may thus access, read, and/or store the proofs 80 of the accountreceivable 50, the account payable 100, and/or the authenticationcredentials 112. Interested debt buyers may inspect the publicblockchain 126, obtain the authentication credentials 78 and 112,retrieve the accounting reports 76 and 110, and bid, buy, or pass.

FIG. 20 illustrates crypto-payments. When the data layer server 122generates the data records 124 in the blockchain data layer 120, anoperator or service provider of the data layer server 122 and/or theblockchain data layer 120 may be compensated. That is, the data layerserver 122 and/or the blockchain data layer 120 provides a service inexchange for any form of compensation. While the compensation may be aconventional currency, FIG. 20 illustrates a cryptographic fee 140.Here, then, the cryptographic fee 140 may be based on the data records124 generated in the blockchain data layer 120. That is, exemplaryembodiments may charge, impose, and/or process the cryptographic fee 140based on the number or quantity of the data records 124 in theblockchain data layer 120. That is, as the data records 124 aregenerated, exemplary embodiments may sum or count the data records 124that are generated over time (such as per second, per minute, or otherinterval). A cloud-based blockchain service, for example, calls orinitializes a counter having an initial value (such as zero). At aninitial time, the counter commences or starts counting or summing thenumber of the data records 124 that are associated with the accountreceivable 50 and/or the account payable 100. The counter stops countingor incrementing at a final time and/or when no more data records 124 aregenerated. Regardless, exemplary embodiments determine or read the finalvalue or count. Exemplary embodiments may then sum or tally a totalnumber of the data records 124 that were generated and perhaps even arate 142 of generation (e.g., the sum or count over time). The serviceprovider may then process the cryptographic fee 140 based on the totalnumber of the data records 124 and/or the rate 142 of generation withinthe blockchain data layer 120.

FIG. 21 illustrates client entities. As the reader may envision, theblockchain data layer 120 may serve many clients or customers. Heremultiple, different entities 150 may each send data describing theiraccount receivables 50 and/or account payables 100 to the data layerserver 122 to receive a blockchain service 152. The data layer server122 may then generate the data records 124 in the blockchain data layer120 as a component of the blockchain service 152. While exemplaryembodiments may be applied to any number of clients, industries, orservices, FIG. 21 illustrates a simple example of four (4) differententities 150 a-d. First entity 150 a, for example, represents a server,operated on behalf of a bank, lender, or other financial institution154, that executes its accounting software application 72 and/or 104 tosend its electronic transactional data 32 a and/or the blockchain 30 a(describing its account receivables 50 and/or account payables 100) tothe data layer server 122. The electronic transactional data 32 a may beraw and unencrypted. However, the electronic transactional data 32 a maybe encrypted (perhaps via the encryption 62 using the cryptographic keythat is unique to the financial institution 154 and/or the accountingsoftware application 72 and/or 104). The financial institution 154 mayadditionally or alternatively sends its blockchain 30 a to the datalayer server 122. However the electronic transactional data 32 a isreceived and discerned, the data layer server 122 then generates thedata records 124 in the blockchain data layer 120.

Other entities may also be served. As FIG. 21 further illustrates, asecond entity 150 b represents a server, operated on behalf of anyretailer 156 (such as HOME DEPOT®, KOHL'S®, or WALMART®), that sendsand/or encrypts its electronic transactional data 32 b (perhaps as itsblockchain 30 b). Third entity 150 c represents a website 158 offering aservice 160 (such as AMAZON®, NETFLIX®, or GOOGLE®) that sends and/orencrypts its electronic transactional data 32 c (perhaps as itsblockchain 30 c). Fourth entity 150 d represents an automotive or othermanufacturer or supplier 162 (such as FORD®, TOYOTA®, or DELPHI®) thatsends and/or encrypts its electronic transactional data 32 d (perhaps asits blockchain 30 d). The entities 150 a-d may thus use their respectivesoftware applications 72 a-d or 104 a-d to provide a first layer 164 ofcryptographic hashing. Each entity 150 a-d may then send theirrespective private blockchains 30 a-d to the blockchain data layer 120,and the blockchain data layer 120 may add a second layer 166 ofcryptographic hashing. The blockchain data layer 120 thus generates thepublic blockchain 126 as a public resource or utility for recordkeeping. Any entity 150 that subscribes to the blockchain data layer 120(such as by acquiring and/or spending a cryptocoinage 168) may thusaccess, read, and/or store the proofs in the public blockchain 126. Theblockchain data layer 120, in other words, acts as the public ledger 132that establishes chain of blocks of immutable evidence.

Cryptocoinage may be exchanged. Each entity 150 a-d may establish itsown private cryptocoinage. Each entity's respective softwareapplications 72 a-d or 104 a-d may create and/or issue its cryptocoinage(such as respective entity-specific tokens). Each entity 150 a-d mayalso establish its own usage restrictions and according to rulesgoverning ownership, trade, and other policies. Each entity 150 a-d maygenerate and sends its respective electronic transaction data 32 a-d tothe blockchain data layer 120 for documentation.

Each entity 150 a-d may also specify their respective digital contract86 a-d. When any of the private blockchains 30 a-d is received, theblockchain data layer 120 may coordinate execution of any digitalcontract 86 a-d. The blockchain data layer 120, for example, may inspectany private blockchain 30 a-d and identify any information associatedwith the digital contract 86 a-d. The blockchain data layer 120 may thenexecute the digital contract 86 a-d, and/or the blockchain data layer120 may identify a service provider that executes the digital contract86 a-d. The blockchain data layer 120, in other words, may manage theexecution of the digital contracts 86 a-d according to a subcontractorrelationship. A provider of the blockchain data layer 120 may then becompensated via any entity's cryptocoinage and/or the blockchain datalayer's cryptocoinage 168.

FIGS. 22-26 are more detailed illustrations of an operating environment,according to exemplary embodiments. FIG. 22 illustrates the supplier'sserver 24 communicating with the data layer server 122 via acommunications network 170. The supplier's server 24 operates on behalfof the supplier 52 and generates the supplier's public or privateblockchain 30. The supplier's server 24 has a processor 172 (e.g.,“μP”), application specific integrated circuit (ASIC), or othercomponent that executes the supplier's accounting software application72 stored in a local memory device 174. The supplier's server 24 has anetwork interface to the communications network 170, thus allowingtwo-way, bidirectional communication with the data layer server 122. Thesupplier's accounting software application 72 includes instructions,code, and/or programs that cause the supplier's server 24 to performoperations, such as generating the electronic transactional data 32representing the account receivable 50. The supplier's accountingsoftware application 72 may also call, invoke, and/or apply acryptographic algorithm that uses the cryptographic keys 64 and/or 74 toencrypt the electronic transactional data 32. Moreover, the supplier'saccounting software application 72 may additionally call, invoke, and/orapply an electronic representation of a hashing algorithm 176 to theunencrypted or encrypted electronic transactional data 32. The hashingalgorithm 176 thus generates one or more hash values 178, which may beincorporated into the blockchain 30. The supplier's accounting softwareapplication 72 then instructs the supplier's server 24 to send theblockchain 30 via the communications network 170 to any destination,such as a network address (e.g., Internet protocol address) associatedwith the data layer server 122.

The digital contract 86 may also be identified. The supplier'saccounting software application 72 may also instruct the supplier'sserver 24 to specify the digital contract 86 as informational content inthe blockchain 30. For example, the digital contract 86 may beidentified by a contract identifier 180. The contract identifier 180 isany digital identifying information that uniquely identifies orreferences the digital contract 86. The contract identifier 180 may bean alphanumeric combination that uniquely identifies a vendor and/orversion of the digital contract 86 and/or a processor or executioner ofthe digital contract 86. The contract identifier 180 may also be one ofthe unique hash values 178 (perhaps generated by the hashing algorithm176) that is included within, or specified by, the blockchain 30.Similarly, the electronic transactional data 32 may identify the partiesto the digital contract 86, their respective performance obligations andterms, and consideration.

FIG. 23 illustrates the blockchain data layer 120. The data layer server122 has a processor 190 (e.g., “μP”), application specific integratedcircuit (ASIC), or other component that executes a data layerapplication 192 stored in a local memory device 194. The data layerserver 122 has a network interface to the communications network 170.The data layer application 192 includes instructions, code, and/orprograms that cause the data layer server 122 to perform operations,such as receiving the electronic transactional data 32, the blockchain30, the digital contract 86, the contract identifier 180, and/or anycontractual parameters associated with the digital contract 86. The datalayer application 192 then causes the data layer server 122 to generatethe blockchain data layer 120. The data layer application 192 mayoptionally call, invoke, and/or apply the hashing algorithm 176 to thedata records 124 contained within the blockchain data layer 120. Thedata layer application 192 may also generate the public blockchain 126.The data layer application 192 may thus generate the public ledger 132that publishes, records, or documents the digital contract 86, thecontract identifier 180, and/or the contractual parameters. Indeed, ifthe data layer application 192 processes and/or manages the digitalcontract 86, the data records 124 may document any processing orexecution, and the data layer application 192 may optionally apply thehashing algorithm 176 to the data records 124 to generate thecryptographic proof 130 of the digital contract 86.

FIG. 24 illustrates the debtor's server 102. The debtor's server 102communicates with the data layer server 122 via the communicationsnetwork 170. The debtor's server 102 operates on behalf of the debtor 56and generates the debtor's public or private blockchain 30. The debtor'sserver 102 has a processor 200 (e.g., “μP”), application specificintegrated circuit (ASIC), or other component that executes the debtor'saccounting software application 104 stored in a local memory device 202.The debtor's server 102 has a network interface to the communicationsnetwork 170, thus allowing two-way, bidirectional communication with thedata layer server 122. The debtor's accounting software application 104includes instructions, code, and/or programs that cause the debtor'sserver 102 to perform operations, such as generating the electronictransactional data 32 representing the account payable 100. The debtor'saccounting software application 104 may also call, invoke, and/or applya cryptographic algorithm that uses the debtor's cryptographic key 106to encrypt the electronic transactional data 32. Moreover, the debtor'saccounting software application 104 may additionally call, invoke,and/or apply an electronic representation of the hashing algorithm 176to the unencrypted or encrypted electronic transactional data 32. Thehashing algorithm 176 thus generates one or more hash values 178, whichmay be incorporated into the blockchain 30. The debtor's accountingsoftware application 104 then instructs the debtor's server 102 to sendthe blockchain 30 via the communications network 170 to any destination,such as the network address (e.g., Internet protocol address) associatedwith the data layer server 122.

The digital contract 86 may also be identified. The debtor's accountingsoftware application 104 may also instruct the debtor's server 102 tospecify the digital contract 86 as informational content in theblockchain 30. For example, the digital contract 86 may be identified bythe contract identifier 180. Similarly, the electronic transactionaldata 32 may identify the parties to the digital contract 86, theirrespective performance obligations and terms, and consideration.

The blockchain data layer 120 may be generated. The data layer server122 receives the electronic transactional data 32, the blockchain 30,the digital contract 86, the contract identifier 180, and/or anycontractual parameters associated with the digital contract 86. The datalayer application 192 then causes the data layer server 122 to generatethe blockchain data layer 120. The data layer application 192 mayoptionally call, invoke, and/or apply the hashing algorithm 176 to thedata records 124 contained within the blockchain data layer 120. Thedata layer application 192 may also generate the public blockchain 126.

FIG. 25 illustrates an additional publication mechanism. Once the datarecords 124 are generated, the data layer server 122 may generate anddistribute the public blockchain 126 to subscribers and to otherparties. For example, suppose the client server 82 is an authorizeddestination or subscriber for the public blockchain 126. The data layerapplication 192 instructs the data layer server 122 to send the publicblockchain 126 (via the communications network 170 illustrated in FIGS.22-24) to the network address (e.g., Internet protocol address)associated with the client server 82. Once the client server 82 receivesthe public blockchain 126, the client server 82 has a hardware processorand solid-state memory device (not shown for simplicity) that stores andexecutes the client-side software application 84. The client-sidesoftware application 84, when executed, has programming or code thatinstructs or causes the client server 82 to perform operations, such asreceiving the public blockchain 126, reading one or more of its blocksof data, and comparing any data or information that describes theaccount receivable 50 and/or the account payable 100. The client server82 may then make or infer a decision to buy, or decline to buy, theaccount receivable 50. Moreover, the client-side software application 84may also initiate a cryptocoinage transaction in exchange for the publicblockchain 126.

FIG. 26 illustrates still more publication mechanisms. Once theblockchain data layer 120 is generated, the blockchain data layer 120may be published in a decentralized manner to any destination. The datalayer server 122, for example, may generate and distribute the publicblockchain 126 (via the communications network 170 illustrated in FIGS.22-24) to one or more federated servers 210. While there may be manyfederated servers 210, for simplicity FIG. 26 only illustrates two (2)federated servers 210 a and 210 b. The federated servers 210 a and 210 bprovide a service and, in return, they are compensated according to acompensation or services agreement or scheme.

Exemplary embodiments include still more publication mechanisms. Forexample, the cryptographic proof 130 and/or the public blockchain 126may be sent (via the communications network 170 illustrated in FIGS.22-24) to a server 212. The server 212 may then add another, third layerof cryptographic hashing (perhaps using the hashing algorithm 176) andgenerate another or second public blockchain 214. While the server 212and/or the public blockchain 126 may be operated by, or generated for,any entity, exemplary embodiments may integrate another cryptographiccoin mechanism. That is, the server 212 and/or the public blockchain 126may be associated with BITCOIN®, ETHEREUM®, RIPPLE®, or othercryptographic coin mechanism. The cryptographic proof 130 and/or thepublic blockchain 126 may be publicly distributed and/or documented asevidentiary validation. The cryptographic proof 130 and/or the publicblockchain 126 may thus be historically and publicly anchored for publicinspection and review.

Exemplary embodiments may be applied regardless of networkingenvironment. Exemplary embodiments may be easily adapted to stationaryor mobile devices having cellular, wireless fidelity (WI-FI®), nearfield, and/or BLUETOOTH® capability. Exemplary embodiments may beapplied to mobile devices utilizing any portion of the electromagneticspectrum and any signaling standard (such as the IEEE 802 family ofstandards, GSM/CDMA/TDMA or any cellular standard, and/or the ISM band).Exemplary embodiments, however, may be applied to anyprocessor-controlled device operating in the radio-frequency domainand/or the Internet Protocol (IP) domain. Exemplary embodiments may beapplied to any processor-controlled device utilizing a distributedcomputing network, such as the Internet (sometimes alternatively knownas the “World Wide Web”), an intranet, a local-area network (LAN),and/or a wide-area network (WAN). Exemplary embodiments may be appliedto any processor-controlled device utilizing power line technologies, inwhich signals are communicated via electrical wiring. Indeed, exemplaryembodiments may be applied regardless of physical componentry, physicalconfiguration, or communications standard(s).

Exemplary embodiments may utilize any processing component,configuration, or system. Any processor could be multiple processors,which could include distributed processors or parallel processors in asingle machine or multiple machines. The processor can be used insupporting a virtual processing environment. The processor could includea state machine, application specific integrated circuit (ASIC),programmable gate array (PGA) including a Field PGA, or state machine.When any of the processors execute instructions to perform “operations,”this could include the processor performing the operations directlyand/or facilitating, directing, or cooperating with another device orcomponent to perform the operations.

Exemplary embodiments may packetize. When the supplier's server 24, theclient server 84, the debtor's server 102, and the data layer server 122communicate via the communications network 170, the supplier's server24, the client server 84, the debtor's server 102, and the data layerserver 122 may collect, send, and retrieve information. The informationmay be formatted or generated as packets of data according to a packetprotocol (such as the Internet Protocol). The packets of data containbits or bytes of data describing the contents, or payload, of a message.A header of each packet of data may contain routing informationidentifying an origination address and/or a destination address.

FIGS. 27-31 further illustrate the blockchain data layer 120, accordingto exemplary embodiments. The blockchain data layer 120 chains hasheddirectory blocks 220 of data into the public blockchain 126. Forexample, the blockchain data layer 120 accepts input data (such as thesupplier's or debtor's blockchain 30 illustrated in FIGS. 1-21) within awindow of time. While the window of time may be configurable fromfractions of seconds to hours, exemplary embodiments use ten (10) minuteintervals. FIG. 27 illustrates a simple example of only three (3)directory blocks 220 a-c of data, but in practice there may be millionsor billions of different blocks. Each directory block 220 of data islinked to the preceding blocks in front and the following or trailingblocks behind. The links are created by hashing all the data within asingle directory block 220 and then publishing that hash value withinthe next directory block.

As FIG. 28 illustrates, published data may be organized within chains222. Each chain 222 is created with an entry that associates acorresponding chain identifier 224. Each entity 32 a-f, in other words,may have its corresponding chain identifier 224 a-d. The blockchain datalayer 120 may thus track any data associated with the entity 150 a-fwith its corresponding chain identifier 224 a-d. New and old data intime may be associated with, linked to, identified by, and/or retrievedusing the chain identifier 224 a-d. Each chain identifier 224 a-d thusfunctionally resembles a directory 226 a-d (e.g., files and folders) fororganized data entries according to the entity 32 a-f.

FIG. 29 illustrates the data records 124 in the blockchain data layer120. As data is received as an input (such as the blockchain 30 and/orthe digital contract 86 illustrated in FIGS. 1-21), data is recordedwithin the blockchain data layer 120 as an entry 228. While the data mayhave any size, small chunks (such as 10 KB) may be pieced together tocreate larger file sizes. One or more of the entries 228 may be arrangedinto entry blocks 230 representing each chain 222 according to thecorresponding chain identifier 224. New entries for each chain 222 areadded to their respective entry block 230 (again perhaps according tothe corresponding chain identifier 224). After the entries 228 have beenmade within the proper entry blocks 230, all the entry blocks 230 arethen placed within in the directory block 220 generated within oroccurring within a window 232 of time. While the window 232 of time maybe chosen within any range from seconds to hours, exemplary embodimentsmay use ten (10) minute intervals. That is, all the entry blocks 230generated every ten minutes are placed within in the directory block220. The electronic transactional data 32 representing the accountreceivable 50 and/or the account payable 100 may thus be carried intothe data records 124 in the blockchain data layer 120.

FIG. 30 illustrates cryptographic hashing. The data layer server 122executes the data layer application 192 to generate the data records 124in the blockchain data layer 120. The data layer application 192 maythen instruct the data layer server 122 to execute the hashing algorithm176 on the data records 124 (such as the directory block 220 illustratedin FIGS. 27-29). The hashing algorithm 176 thus generates one or morehash values 178 as a result, and the hash values 178 represent thehashed data records 124. As one example, the blockchain data layer 120may apply a Merkle tree analysis to generate a Merkle root (representinga Merkle proof 130) representing each directory block 220. Theblockchain data layer 120 may then publish the Merkle proof 130 (as thisdisclosure explains).

FIG. 31 illustrates hierarchical hashing. The entity's accountingsoftware application 72/104 provides the first layer 164 ofcryptographic hashing and generates the public or private blockchain 30.The entity 150 then sends its blockchain 30 (perhaps referencing orspecifying the account receivable 50 and/or the account payable 100and/or digital contract 86) to the data layer server 122. The data layerserver 122 generates the blockchain data layer 120. The data layerapplication 192 may optionally provide the second or intermediate layer166 of cryptographic hashing to generate the cryptographic proof 130.The data layer server 122 may also publish any of the data records 124as the public blockchain 126, and the cryptographic proof 130 may or maynot also be published via the public blockchain 126. The publicblockchain 126 and/or the cryptographic proof 130 may be optionally sentto the server 212 as an input to yet another public blockchain 214(again, such as BITCOIN®, ETHEREUM®, or RIPPLE®) for a third layer 240of cryptographic hashing and public publication. The first layer 164 andthe second layer 166 thus ride or sit atop a conventional publicblockchain 214 (again, such as BITCOIN®, ETHEREUM®, or RIPPLE®) andprovide additional public and/or private cryptographic proofs 130.

Exemplary embodiments may use any hashing function. Many readers may befamiliar with the SHA-256 hashing algorithm. The SHA-256 hashingalgorithm acts on any electronic data or information to generate a256-bit hash value as a cryptographic key. The key is thus a uniquedigital signature. There are many hashing algorithms, though, andexemplary embodiments may be adapted to any hashing algorithm.

FIGS. 32-35 are more detailed illustrations of the account receivable50, according to exemplary embodiments. The server 24 sends theblockchain 30 to the network address associated with the data layerserver 122 that generates the blockchain data layer 120. The blockchain30 may contain the electronic transactional data 32 describing theaccount receivable 50 (perhaps as one or more hashed blocks of data).For example, the electronic transactional data 32 may include an accountreceivable identifier 250 that is assigned to the account receivable 50.The account receivable identifier 250 uniquely identifies the accountreceivable 50. While the account receivable identifier 250 may have anystructure or form, the account receivable identifier 250 is perhaps bestunderstood as a unique alphanumeric or ASCII string that is assigned bythe supplier's accounting software application 72. If the accountreceivable identifier 250 is hashed (using the hashing algorithm 176),the resulting hash value 178 may uniquely identify any blocks 28 of datain the blockchain 30 that reference the account receivable 50. Theaccount receivable identifier 250 may additionally or alternatively beseparately sent from the server 24 to the data layer server 122. Becausethe electronic transactional data 32 (and/or its corresponding hashvalue(s) 178) is an identifiable input to the data layer server 122generating the blockchain data layer 120, the data records 124 may alsocarry or reference any portion of the any the electronic transactionaldata 32. For example, any of the data records 124 may also reference, beidentified by, or be associated with the supplier 52, the debtor 56,and/or the account receivable identifier 250. Any of the electronictransactional data 32 may thus be a common indicator or reference datafor tracking any transaction records documenting payments 40 on theaccount receivable 50. As a simple example, once the account receivableidentifier 250 is assigned to the account receivable 50, any of the datarecords 124 in the blockchain data layer 120 may thus be commonly mappedor identified by the account receivable identifier 250 that is uniquelyassociated with the account receivable 50.

FIG. 33 illustrates a simple illustration. Once any of the electronictransactional data 32 (and/or its corresponding hash value) is received,the electronic transactional data 32 may propagate and be recordedwithin the blockchain data layer 120. The account receivable identifier250, for example, may be recorded in any of the entries 228. The entry228, and thus the account receivable identifier 250, may then berecorded and/or arranged as the entry block 230 and placed within thedirectory block 220. The entry 228, the entry block 230, and thedirectory block 220 may thus reference, specify, or be associated with,the account receivable identifier 250. The account receivable identifier250 has thus propagated as informational content from the blockchain 30and into and through the blockchain data layer 120. The accountreceivable identifier 250 thus hierarchically moves through the multiplelayers of cryptographic hashing for public publication. The blockchaindata layer 120 thus tracks any records of the subsequent transactionsinvolving the account receivable identifier 250. In simple words, theblockchain data layer 120 may track payments, contractual performance,and/or satisfaction of the account receivable 50 via the data records124 that reference or contain the account receivable identifier 250.Moreover, the blockchain data layer 120 may also track ownership andtransfer of the account receivable 50, all via the common accountreceivable identifier 250.

FIG. 34 illustrates a query mechanism. Here the data layer server 122may be queried to identify the data records 124 that match a queryparameter 260. The data layer server 122 receives a query 262 from anyoriginating device 264. While the query 262 may be sent by the clientserver 82 (such as illustrated by FIG. 25), FIG. 33 illustrates asmartphone 266. Because most readers are thought familiar with mobilecomputing, the data layer application 192 may be configured to permitqueries from any authorized device or user via the smartphone 266. Thesmartphone 266 has a hardware processor and solid-state memory device(not shown) that store and execute a mobile application 268. The mobileapplication 268 comprises code or instructions that cause the smartphone266 to perform operations, such as generating a graphical user interface270 that allows a user to input the query parameter 260. The mobileapplication 268 instructs the smartphone 266 to generate the query 262specifying the query parameter 260. The mobile application 268 instructsthe smartphone 266 to send the query 262 to the network addressassociated with the data layer server 122. When the data layer server122 receives the query 262, the data layer server 122 may then consultor access a database 270 of data layer records. The database 270 of datalayer records provides a referential record of the informational contentcontained within the blockchain data layer 120.

FIG. 35 further illustrates the database 270 of data layer records. FIG.35 illustrates the data layer server 122 locally storing the database270 of data layer records in its local memory device 194, but thedatabase 270 of data layer records may be remotely stored and accessedvia the communications network 170 (illustrated in FIGS. 22-24).Regardless, the data layer server 122 may query the database 270 of datalayer records for any of the electronic transactional data 32 (and/orits corresponding hash value) and identify and/or retrieve anycorresponding data records 124. While the database 270 of data layerrecords may have any logical structure, a relational database is thoughtthe easiest to understand. FIG. 35 thus illustrates the database 270 ofdata layer records as a table 272 that maps, converts, or translates theelectronic transactional data 32 (such as the account receivableidentifier 250) to its corresponding contract identifier 180 and/or toits corresponding entry 228, entry block 230, and/or directory block 220within the blockchain data layer 120. Whenever the data layer server 122generates the entry 228, entry block 230, and/or directory block 220,the data layer server 122 may add an entry to the database 270 of datalayer records. Over time, then, the database 270 of data layer tracks acomprehensive historical repository of the electronic transactional data32. The data layer server 122 may then read or retrieve the entry 228,entry block 230, and/or directory block 220 containing or correspondingto the electronic transactional data 32. Moreover, because each entry228, entry block 230, and/or directory block 220 may be time-stampedwith a date and time, the database entries in the database 270 of datalayer records may be retrieved and chronologically arranged to revealany sequence or series of payments and transactions.

Returning to FIG. 34, a query response 274 is generated. The data layerserver 122 identifies any database entries that match or sufficientlysatisfy the query parameter 260. The data layer application 192 may theninstruct the data layer server 122 to generate the query response 274comprising or specifying any of the related database entries. The datalayer application 192 may then instruct the data layer server 122 tosend the query response 274 via the communications network 170(illustrated in FIGS. 22-24) to the network address (e.g., Internetprotocol address) associated with the requesting client device (such asthe smartphone 266). The mobile application 268 may then instruct thesmartphone 266 to generate the graphical user interface 270 thatdisplays the query response 274.

FIGS. 36-37 are more detailed illustrations of the account payable 100,according to exemplary embodiments. The debtor's server 102 sends theblockchain 30 to the network address associated with the data layerserver 122 that generates the blockchain data layer 120. The blockchain30 may contain the electronic transactional data 32 describing theaccount payable 100 (perhaps as one or more hashed blocks of data). Forexample, the electronic transactional data 32 may include an accountpayable identifier 280 that is assigned to the account payable 100. Theaccount payable identifier 280 uniquely identifies the account payable100. While the account payable identifier 280 may have any structure orform, the account payable identifier 280 is perhaps best understood as aunique alphanumeric or ASCII string that is assigned by the debtor'saccounting software application 104. If the account payable identifier280 is hashed (using the hashing algorithm 176), the resulting hashvalue 178 uniquely identifies any blocks 28 of data in the blockchain 30that reference the account payable 100. The account payable identifier280 may additionally or alternatively be separately sent from thedebtor's server 102 to the data layer server 122. Because the electronictransactional data 32 (and/or its corresponding hash value(s) 178) is anidentifiable input to the data layer server 122 generating theblockchain data layer 120, the data records 124 may also carry orreference any portion of the electronic transactional data 32. Forexample, any of the data records 124 may also reference, be identifiedby, or be associated with the supplier 52, the debtor 56, and/or theaccount payable identifier 280. Any of the electronic transactional data32 may thus be a common indicator or reference data for tracking anytransaction records documenting payments 40 on the account payable 100.As a simple example, once the account payable identifier 280 is assignedto the account payable 100, any of the data records 124 in theblockchain data layer 120 may thus be commonly mapped or identified bythe account payable identifier 280 that is uniquely associated with theaccount payable 100.

FIG. 37 also illustrates the database 270 of data layer records. Thedatabase 270 of data layer records may be a comprehensive repositorythat relates any electronic transactional data 32 (such as the supplier52 and/or debtor 56) to its corresponding account receivable identifier250, account payable identifier 280, contract identifier 180, and/orentry 228, entry block 230, and directory block 220 within theblockchain data layer 120. The data layer server 122 may thus quicklyand easily query the database 270 of data layer records for any of theelectronic transactional data 32 (and/or its corresponding hash value)and identify and/or retrieve any corresponding data records 124. Anyelectronic transactional data 32 may thus be mapped or associated withthe database entries in the database 270 of data layer records. Again,any of the database entries may be retrieved and chronologicallyarranged to reveal any sequence or series of payments and transactions.

FIG. 38 illustrates the login procedure 80, according to exemplaryembodiments. As this disclosure above explained, the client server 82may receive the blockchain 30, read the supplier's authenticationcredentials 78, log in to the supplier's accounting software application72, and access the supplier's accounting report 76. While any accessmechanism may be used, most readers are thought familiar with online orInternet web access. That is, the client-side software application 84calls or invokes a web browser 282 to request and download a webpage284. The webpage 284 is processed and its login procedure 80 isautogenerated and/or completed using the authentication credentials 78specified by the blockchain 30. When the client server 82 authenticatesto the supplier's accounting software application 72, the client-sidesoftware application 84 and/or the web browser 282 may then request anddownload the supplier's accounting report 76 (perhaps formatted as anextensible markup language document). The client server 82 reads anydata contained within the supplier's accounting report 76 and maycompare to the decisional parameters 92. Any third-party debt buyer 58may thus conduct automated due diligence before purchasing the accountreceivable 50.

FIG. 39 illustrates the login procedure 114, according to exemplaryembodiments. As this disclosure above explained, the client server 82may receive the blockchain 30, read the debtor's authenticationcredentials 112, log in to the debtor's accounting software application104, and access the debtor's accounting report 110. Again, while anyaccess mechanism may be used, FIG. 39 illustrates web access. That is,the client-side software application 84 calls or invokes the web browser282 to request and download the debtor's accounting report 110 as thewebpage 284. The webpage 284 is processed and its login procedure 114 isautogenerated and/or completed using the authentication credentials 112specified by the blockchain 30. When the client server 82 authenticatesto the debtor's accounting software application 104, the client-sidesoftware application 84 and/or the web browser 282 may then request anddownload the debtor's accounting report 110 (perhaps formatted as anextensible markup language document). The client server 82 reads anydata contained within the debtor's accounting report 110 and may compareto the decisional parameters 92. Any third-party debt buyer 58 may thusconduct automated due diligence before purchasing the account receivable50 and/or the account payable 100.

The login procedures 80 and 114 may also be performed by the data layerserver 122. This disclosure above explains that the data layer server122 may receive the blockchain 30 sent from the server 24 and/or thedebtor server 102 (see, for example, FIGS. 18-19). Because theblockchain 30 may specify the supplier's authentication credentials 78and/or the debtor's authentication credentials 112, the data layerserver 122 may log in to the accounting software applications 72 and/or104 and retrieve the accounting reports 76 and 110. The data layerapplication 192 may utilize Internet online web access via the webbrowser 282 to request and download the accounting reports 76 and 110 asthe one or more webpages 284. The data layer application 192 may readany data contained within the accounting reports 76 and 110 and maycompare to the decisional parameters 92. Any third-party debt buyer 58may thus conduct automated due diligence before purchasing the accountreceivable 50.

FIG. 40 is a flowchart illustrating a method or algorithm for debttransactions, according to exemplary embodiments. The blockchain 30 isreceived (Block 300) and the block 28 of data is read to identify datarepresenting the account receivable 50 and/or the account payable 100(Block 302). The verification 60 may be performed as due diligence(Block 304). The account receivable 50 and/or the account payable 100may be compared to the decisional parameters 92 (Block 306). If theaccount receivable 50 and/or the account payable 100 satisfies thedecisional parameters 92 (Block 308), then the smart contract 86 mayhave authority to purchase the account receivable 50 (Block 310). Thesmart contract 86 may conduct an electronic financial transaction (suchas a crypto-coinage transaction) associated with the purchase of theaccount receivable 50 (Block 312). However, if the account receivable 50and/or the account payable 100 fails to satisfy the decisionalparameters 92 (Block 308), then the smart contract 86 may decline topurchase the account receivable 50 (Block 314).

FIG. 41 is a schematic illustrating still more exemplary embodiments.FIG. 41 is a more detailed diagram illustrating a processor-controlleddevice 350. As earlier paragraphs explained, the supplier's accountingsoftware application 72, the client-side software application 84, thedebtor's accounting software application 104, the data layer application192, and the mobile application 268 may partially or entirely operate inany mobile or stationary processor-controlled device. FIG. 41, then,illustrates the supplier's accounting software application 72, theclient-side software application 84, the debtor's accounting softwareapplication 104, the data layer application 192, and the mobileapplication 268 stored in a memory subsystem of the processor-controlleddevice 350. One or more processors communicate with the memory subsystemand execute either, some, or all applications. Because theprocessor-controlled device 350 is well known to those of ordinary skillin the art, no further explanation is needed.

FIG. 42 depicts other possible operating environments for additionalaspects of the exemplary embodiments. FIG. 42 illustrates the supplier'saccounting software application 72, the client-side software application84, the debtor's accounting software application 104, the data layerapplication 192, and the mobile application 268 operating within variousother processor-controlled devices 350. FIG. 42, for example,illustrates that the supplier's accounting software application 72, theclient-side software application 84, the debtor's accounting softwareapplication 104, the data layer application 192, and the mobileapplication 268 may entirely or partially operate within a set-top box(“STB”) or other media player (352), a personal/digital video recorder(PVR/DVR) 354, a Global Positioning System (GPS) device 356, aninteractive television 358, a tablet computer 360, or any computersystem, communications device, or processor-controlled device utilizingany of the processors above described and/or a digital signal processor(DP/DSP) 362. Moreover, the processor-controlled device 350 may alsoinclude wearable devices (such as watches), radios, vehicle electronics,cameras, clocks, printers, gateways, mobile/implantable medical devices,and other apparatuses and systems. Because the architecture andoperating principles of the various devices 350 are well known, thehardware and software componentry of the various devices 350 are notfurther shown and described.

Exemplary embodiments may be applied to any signaling standard. Mostreaders are thought familiar with the Global System for Mobile (GSM)communications signaling standard. Those of ordinary skill in the art,however, also recognize that exemplary embodiments are equallyapplicable to any communications device utilizing the Time DivisionMultiple Access signaling standard, the Code Division Multiple Accesssignaling standard, the “dual-mode” GSM-ANSI Interoperability Team(GAIT) signaling standard, or any variant of the GSM/CDMA/TDMA signalingstandard. Exemplary embodiments may also be applied to other standards,such as the I.E.E.E. 802 family of standards, the Industrial,Scientific, and Medical band of the electromagnetic spectrum,BLUETOOTH®, and any other.

Exemplary embodiments may be physically embodied on or in acomputer-readable non-transitory storage medium. This computer-readablemedium, for example, may include CD-ROM, DVD, tape, cassette, floppydisk, optical disk, memory card, memory drive, and large-capacity disks.This computer-readable medium, or media, could be distributed toend-subscribers, licensees, and assignees. A computer program productcomprises processor-executable instructions for recording debt in theblockchain marketplace 20, as the above paragraphs explain.

While the exemplary embodiments have been described with respect tovarious features, aspects, and embodiments, those skilled and unskilledin the art will recognize the exemplary embodiments are not so limited.Other variations, modifications, and alternative embodiments may be madewithout departing from the spirit and scope of the exemplaryembodiments.

1. A method performed by a client server that executes a digitalcontact, the method comprising: retrieving, by the client server, anauthentication credential specified by a blockchain, the authenticationcredential associated with an accounting service and associated with anaccount receivable; authenticating, by the client server, to theaccounting service using the authentication credential specified by theblockchain; in response to the authenticating to the accounting serviceusing the authentication credential specified by the blockchain,retrieving, by the client server, an accounting report associated withthe account receivable; and executing, by the client server, the digitalcontract based on the accounting report associated with the accountreceivable.
 2. The method of claim 1, further comprising identifying adebtor specified by the blockchain that is associated with the accountreceivable.
 3. The method of claim 1, further comprising identifying ahash value specified by the blockchain that identifies a debtorassociated with the account receivable.
 4. The method of claim 1,further comprising identifying a supplier specified by the blockchainthat is associated with the account receivable.
 5. The method of claim1, further comprising identifying a hash value specified by theblockchain that identifies a supplier associated with the accountreceivable.
 6. The method of claim 1, further comprising identifying aninvoice specified by the blockchain that is associated with the accountreceivable.
 7. The method of claim 1, further comprising identifying ahash value specified by the blockchain that identifies an invoiceassociated with the account receivable.
 8. A system, comprising: ahardware processor; and a memory device, the memory device storinginstructions that when executed by the hardware processor performoperations, the operations comprising: retrieving an authenticationcredential specified by a blockchain, the authentication credentialassociated with an accounting service and associated with an accountreceivable; authenticating to the accounting service using theauthentication credential specified by the blockchain; in response tothe authenticating to the accounting service using the authenticationcredential specified by the blockchain, retrieving an accounting reportassociated with the account receivable; and executing the digitalcontract based on the accounting report associated with the accountreceivable.
 9. The system of claim 8, wherein the operations furthercomprise identifying a debtor specified by the blockchain that isassociated with the account receivable.
 10. The system of claim 8,wherein the operations further comprise identifying a hash valuespecified by the blockchain that identifies a debtor associated with theaccount receivable.
 11. The system of claim 8, wherein the operationsfurther comprise identifying a supplier specified by the blockchain thatis associated with the account receivable.
 12. The system of claim 8,wherein the operations further comprise identifying a hash valuespecified by the blockchain that identifies a supplier associated withthe account receivable.
 13. The system of claim 8, wherein theoperations further comprise identifying an invoice specified by theblockchain that is associated with the account receivable.
 14. Thesystem of claim 8, wherein the operations further comprise identifying ahash value specified by the blockchain that identifies an invoiceassociated with the account receivable.
 15. A memory device storinginstructions that when executed by a hardware processor performoperations, the operations comprising: retrieving an authenticationcredential specified by a blockchain, the authentication credentialassociated with an accounting service and associated with an accountreceivable; authenticating to the accounting service using theauthentication credential specified by the blockchain; in response tothe authenticating to the accounting service using the authenticationcredential specified by the blockchain, retrieving an accounting reportassociated with the account receivable; and executing the digitalcontract based on the accounting report associated with the accountreceivable.
 16. The memory device of claim 15, wherein the operationsfurther comprise identifying a debtor specified by the blockchain thatis associated with the account receivable.
 17. The memory device ofclaim 15, wherein the operations further comprise identifying a hashvalue specified by the blockchain that identifies a debtor associatedwith the account receivable.
 18. The memory device of claim 15, whereinthe operations further comprise identifying a supplier specified by theblockchain that is associated with the account receivable.
 19. Thememory device of claim 15, wherein the operations further compriseidentifying a hash value specified by the blockchain that identifies asupplier associated with the account receivable.
 20. The memory deviceof claim 15, wherein the operations further comprise identifying aninvoice specified by the blockchain that is associated with the accountreceivable.